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1.  Introduction. 


Recently,  several  proposals  appeared  in  the  literature  dealing  with  security  models 
for  object-oriented  databases.  While  some  of  them  are  of  considerable  interest  and  merit 
(see  Section  6  for  a  discussion  of  related  work),  they  seem  to  lack  in  intuitive  appeal 
because  they  do  not  appear  to  model  security  in  a  way  that  would  take  full  advantage  of 
the  object-oriented  paradigm. 

Our  goal  in  the  present  work  is  to  construct  a  database  security  model  that  dove¬ 
tails  with  the  object-oriented  data  model  in  a  natural  way.  The  result,  we  hope,  is  a  set  of 
principles  to  help  design  and  implement  security  policies  in  a  clear  and  concise  fashion. 

The  object — subject  paradigm  of  Bell  and  LaPadula  [1]  is  widely  used  in  work  on 
security.  An  object  is  understood  to  be  a  data  file  or,  at  an  abstract  level,  a  data  item.  A 
subject  is  an  active  process  that  can  request  access  to  objects.  Every  object  is  assigned  a 
classification,  and  every  subject  a  clearance.  Classifications  and  clearances  are  collec¬ 
tively  referred  to  as  security  levels  (or  classes).  Security  levels  are  partially  ordered.  A 
subject  is  allowed  a  read  access  to  an  object  only  if  the  former’s  clearance  is  equivalent 
to  or  higher  (in  the  partial  order)  than  the  latter’s  classification.  A  subject  is  allowed  a 
write  access  to  an  object  only  if  the  former’s  clearance  is  equivalent  to  or  lower  than  the 
latter’s  classification.  The  above  two  restrictions  are  intended  to  ensure  that  there  is  no 
flow  of  information  from  high  objects  to  low  subjects.  For  otherwise  (since  subjects  can 
represent  users+)  a  breach  of  security  occurs  wherein  a  user  gets  access  to  information 

for  which  he  or  she  has  not  been  cleared. 

It  is  a  mistake,  however,  to  completely  identify  subjects  with  users. 
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Most  security  models  today  are  based  on  the  traditional  Bell — LaPadula  paradigm. 
While  this  paradigm  has  proven  to  be  quite  effective  for  modeling  security  in  operating 
systems  as  well  as  relational  databases,  it  appears  somewhat  forced  when  applied  to 
object-oriented  systems.  The  problem  is  that  the  notion  of  object  in  the  object-oriented 
data  model  does  not  correspond  to  the  Bell — LaPadula  notion  of  object.  The  former 
combines  the  properties  of  a  passive  information  repository,  represented  by  attributes  and 
their  values,  with  the  properties  of  an  active  agent,  represented  by  methods  and  their 
invocations.  Thus,  the  object  of  the  object-oriented  data  model  can  be  thought  of  as  the 
object  and  the  subject  of  the  Bell — LaPadula  paradigm  fused  into  one. 

Continuing  the  examination  of  the  object-oriented  model  from  the  security  angle, 
one  arrives  at  the  realization  that  information  flow  in  this  context  has  a  very  concrete  and 
natural  embodiment  in  the  form  of  messages.  Moreover,  taking  into  a<  count  encapsula¬ 
tion,  a  cardinal  property  of  object-oriented  systems,  messages  can  be  considered  the  only 
instrument  of  information  flow. 

The  main  elements  of  the  proposed  model  can  be  sketched  out  as  follows.  The  sys¬ 
tem  consists  of  objects  (in  the  new,  object-oriented  sense).  Every  object  is  assigned  a 
unique  classification.  Objects  can  communicate  (and  exchange  information)  only  by 
means  of  sending  messages  among  themselves.  However,  messages  are  not  allowed  to 
flow  directly  from  one  object  to  another.  Instead  every  message  is  intercepted  by  the 
message  filter,  a  system  element  charged  with  implementing  security  policies.  The  mes¬ 
sage  filter  decides,  upon  examining  a  given  message  and  the  classifications  of  the  sender 
and  receiver,  what  action  is  appropriate.  It  may  let  the  message  go  through  unaltered;  or 
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it  may  completely  reject  it  (e.g.,  when  a  low  object  sends  a  message  to  a  high  object 
requesting  the  value  of  one  of  the  latter’s  attributes);  or  it  may  take  some  other  action  (to 
be  discussed  later). 

The  main  advantages  of  the  proposed  model  are  its  compatibility  with  the  object- 
oriented  data  model  and  the  simplicity  and  conceptual  clarity  with  which  security  poli¬ 
cies  can  be  stated  and  enforced. 

One  comment  is  in  order  at  this  point.  Even  though  all  objects  are  single-level  (in 
the  sense  of  having  a  unique  classification  assigned  to  the  entire  object  and  not  assigning 
any  classifications  to  individual  attributes  or  methods),  this  does  not  preclude  the  possi¬ 
bility  of  modeling  multilevel  entities,  as  will  be  demonstrated  later. 

In  this  paper,  w-e  focus  on  the  problem  of  mandatory  access  control.  Discretionary 
access  control  is  not  addressed  here. 
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2.  Object-Oriented  Data  Model. 


An  object-oriented  database  is  a  collection  of  objects  communicating  via  messages. 
Each  object  consists  of  a  unique  identifier,  a  set  of  attributes  and  a  set  of  methods,  the 
latter  being  essentially  pieces  of  code.  Each  attribute  has  a  value,  which  can  change  over 
time. 

An  object  can  invoke  one  of  its  methods  in  response  to  a  message  received  from 
another  object.  A  method  invocation  can,  in  turn,  (1)  directly  access  an  attribute  belong¬ 
ing  to  the  object  (read  or  change  its  value);  (2)  invoke  other  methods  belonging  to  the 
object;  (3)  send  a  message  to  another  object;  or  (4)  create  a  new  object. 

There  is  a  special  type  of  object,  called  user  object.  A  user  object  represents  a  user 
session  with  the  system.  User  objects  differ  from  regular  objects  in  that,  in  addition  to 
being  able  to  invoke  methods  in  response  to  messages,  they  can  also  invoke  methods 
spontaneously.*  User  object  can  be  created  only  by  the  system,  at  the  login  time. 

Let  us  formalize  now  the  central  elements  of  the  object-oriented  data  model.  We 
postulate  a  finite  set  of  domains  D  i,  D2,  ...,  Dn.  Let  D  be  the  union  of  the  domains  aug¬ 
mented  with  a  special  element  nil,  i.e.,  0=0]  uD2u  •  •  •  uD„u(/iil).  Every  ele¬ 
ment  of  D  is  referred  to  as  a  primitive  object.  Let  A  be  a  set  of  symbols  called  attribute 


x 

The  notion  of  spontaneous  method  invocation  may  seem  rather  arbitrary  at  first.  It  is,  however, 
necessary  in  order  to  avoid  running  into  a  version  of  the  chicken-and-egg  paradox.  Namely,  if  a 
message  can  be  sent  only  through  a  method  invocation  (see  property  (3)  of  method  invocations) 
and  if  a  method  can  be  activated  only  by  a  message  received  from  another  object,  then  how  docs 
any  processing  in  such  a  system  ever  get  initiated?  (One  has  to  insist  that  cither  the  egg  or  the 
chicken  come  first.)  In  reality,  we  want  a  user  to  be  able  to  initiate  a  system  activity,  c.g.,  by 
typing  a  string  of  characters  on  the  keyboard.  This  would  serve  as  a  signal  for  the  corresponding 
user  object  to  initiate  a  method.  We  choose  to  think  of  this  as  a  "spontaneous"  initiation,  because 
the  keyboard  and  any  signals  that  it  sends  arc  external  to  our  model. 
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names,  J  a  set  of  identifiers,  and  M  a  set  of  finite  strings  of  code  called  methods.  Let  V  be 
a  set  of  values  defined  as  follows:  V  =  D  ul.  That  is,  a  value  is  either  a  primitive  object 
or  an  identifier.  * 

Definition  1.  An  object  is  either  a  primitive  object  or  a  quadruple  o  =  (i,  a,  v,  p) 
such  that  i  e  I,  a  =  (  a  j,  a *)  where  a}  e  A  for  all  j  (1  <j  <  k),  v  =  ( vl5  v*)  where 
v j  e  V  for  all  j  ( 1  <  j  <  k),  and  p  c  M.  □ 

Definition  1  states  that  an  object  is  defined  by  its  identifier,  an  ordered  set  of  attri¬ 
bute  names,  an  ordered  set  of  corresponding  values,  and  a  set  of  methods.  We  assume 
that  every  object  has  a  unique  identifier,  i.e.,  for  any  two  objects  os  =  ( is,  as,  v5,  pj  and 
o,  =  ( it,  at,  vt,  pf ),  os  =  o,  iff  is  =  it.  The  uniqueness  of  object  identity  is  commonly 
considered  a  fundamental  property  of  object-oriented  systems  [6]. 

We  will  use  the  following  notation  in  the  rest  of  the  paper.  Let  os  =  ( is,  as,  Vy,  p5) 
be  an  object.  Then  i ( o5)  denotes  the  object  identifier,  is\  a{  os )  denotes  the  list  of  attri¬ 
butes,  as\  v  ( os )  denotes  the  list  of  attribute  values,  v5,  and  p(  os)  denotes  the  object’s  set 
of  methods,  Py. 

Definition  2.  A  message  is  a  triple  g  =  (  h,  p,  r)  where  h  is  the  message  name, 
p  =  (p i,  ...,  Pk),  k>  0,  is  an  ordered  set  (list)  of  primitive  objects  or  object  identifiers 
called  the  message  parameters,  and  r  is  the  return  value.  □ 

Similarly  to  the  notation  used  for  objects,  we  let  h(  g),  p{  g),  and  r(g)  denote  the 

name,  the  parameter  list,  and  the  return  value  of  message  g  respectively. 

*  A  more  general  object  model  would  also  permit  a  value  to  be  a  set  of  identifiers  by  defining 
V  =  D  KJ  l  KJ  2  .  However,  for  the  sake  of  simplicity  we  forego  this  generalization  in  the 
present  paper.  The  results  developed  here  do  not  depend  on  this  simplification. 
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An  object  sends  a  message  by  invoking  a  system  primitive  SEND  ( g,  i )  where  i  is 
the  identifier  of  the  receiver  object.  The  value  r(  g)  is  computed  by  the  method  activated 
in  the  receiver  upon  the  arrival  of  g  there  and  returned  to  the  sender.** 

Definition  3.  The  interface  fQ  of  object  o  is  a  function  f0:H  — >  p(  o) u  {void} 
where  H  is  a  set  of  all  possible  message  names.  □ 

The  interface  of  object  o  determines  which  messages  o  responds  to.  Those  are  the 
messages  whose  names,  h,  are  such  that  f0(  h )  *  void.  If  fQ(  h)  =  void,  o  does  not 
respond  to  messages  whose  name  is  h.  Moreover,  the  interface  determines  which  partic¬ 
ular  method,  out  of  the  set  of  methods,  (i(o),  defined  for  object  o,  is  to  be  invoked, 
depending  on  the  name  of  the  given  message. 

We  have  defined  methods  as  strings  of  code.  Now  we  are  in  a  position  to  give  a 
more  formal  definition  of  methods. 

Definition  4.  Let  o  be  an  object.  A  method  m  defined  for  o  (m  e  |i)  is  a  function 
m:/>— »2a(o)xVx2Gx/xV  where  P  is  a  set  of  all  possible  parameter  lists.  □ 

Definition  4  states  that  a  method  maps  a  list  of  parameters  into  a  triple.  The  first  ele¬ 
ment  of  the  triple  is  a  set  (possibly  empty)  of  attribute-name— attribute-value  pairs  where 
the  names  are  drawn  from  the  set  of  the  object’s  attribute  names.  The  second  element  is 
a  set  (possibly  empty)  of  message — identifier  pairs.  The  third  element  is  a  value  (a  primi¬ 
tive  object  or  an  object  identifier). 

**  As  wc  shall  see  in  the  next  section,  sometimes  the  security  component  of  the  system  will  have 
to  interfere  in  the  matter  of  computing  r(g). 


6 


In  response  to  a  message  g  =  ( h,  p,  r),  an  object  o  invokes  a  method  m  e  p(  o) 
such  that  m  =  fQ{  h)  (we  assume  that  f0(  h)  *  void).  Then,  the  value  m  ( p)  is  computed 
(this  corresponds  to  executing  the  method’s  code  with  the  argument  list  p).  The  compu¬ 
tation  results  in  m{p)  =  (  {  (  au  v1  ( as ,  vs)},  [(g\,  i i),  (g,,  /<)},  v;j).  The 

semantics  of  this  are  as  follows.  Attributes  a\,  ....  as  of  o  are  updated  with  new  values 
v  i ,  ...,  respectively;  messages  g  i ,  gt  are  sent  to  the  objects  with  identifiers  i  x it 
respectively;  and  vy  is  returned  to  the  sender  of  g.  Note  that  for  some  k  we  could  have 
4  =  i{  o),  i.e.,  an  object  can  send  a  message  to  itself.  This,  for  instance,  can  serve  as  a 
mechanism  for  invoking  other  methods  within  the  same  object. 

Objects  are  used  to  model  real-world  entities. *  This  is  done  by  associating  proper¬ 
ties,  or  facets,  of  an  entity  with  attributes  of  the  corresponding  object.  The  attribute 
values  are,  then,  instantiations  of  those  properties.  For  instance,  a  country  can  be 
represented  in  a  geographic  object-oriented  database  by  an  object  o  where  a(o)  = 
(COUNTRY_NAME,  POPULATION,  CAPITAL,  NATIONAL_FLAG, 
FORM_OF_GOVERNMENT)  and  v ( o)  =  (“Albania”,  1 17,  i ( o\ ),  i(o 2),  i ( 03))-  The 
values  of  the  first  and  second  attributes  are  a  string  and  an  integer,  respectively;  the 
values  of  the  rest  of  the  attributes  are  references  to  other  objects  that,  in  turn,  describe  the 
capital,  the  national  flag,  and  the  form  of  government  of  the  nation  of  Albania. 

Note  that  an  object’s  methods,  unlike  its  attributes,  do  not  have  counterparts  in  the 
real-world  entity  modeled  by  the  object.  The  purpose  of  methods  is  quite  different.  It  is  to 
provide  support  for  basic  database  functionality  such  as  querying  and  updating  objects. 

x 

As  wc  will  see  later,  a  single  entity  may  be  modeled  by  more  than  one  object. 
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A  realistic  object-oriented  model  should  also  contain  the  notion  of  constraints.  For 


instance,  an  attribute  of  an  object  may  be  allowed  to  assume  values  only  from  a  restricted 
subset  of  domains  or  object  identifiers.  To  simplify  the  exposition,  we  choose  to  disre¬ 
gard  the  issue  of  constraints  in  this  paper.  However,  it  should  be  a  simple  matter  to  incor¬ 
porate  this  notion  in  our  security-data  model. 
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3.  Object-Oriented  Security  Model. 


An  informal  exposition  of  our  security  model  was  given  in  Section  1  in  terms  of 
objects  with  unique  security  level  assignments  exchanging  messages  subject  to  some 
security  constraints.  This  section  is  devoted  to  developing  a  formal  model  of  object- 
oriented  security,  in  accordance  with  that  general  idea. 

3.1.  Security  Levels  and  Information  Flow. 

The  system  consists  of  a  set  O  of  objects  (see  Definition  1)  and  a  partially  ordered 
set  S  of  security  levels  with  ordering  relation  <.  A  level  5,  e  S  is  said  to  be  dominated  by 
another  level  Sj  e  S,  this  being  denoted  by  S,  <  SJt  if  i  =  j  or  5,  <  Sj.  For  two  levels  S, 
and  Sj  that  are  unordered  by  <,  we  write  Si  <>  Sj. 

There  is  a  total  function  L:0  -*S,  called  security  classification  function,  i.e.,  for 
every  o  c-  O,  L(  o)  e  S.  In  other  words,  every  object  has  a  unique  security  level  associ¬ 
ated  with  it. 

3.2.  Characterization  of  Information  Flows. 

The  main  goal  of  a  security  policy  must  be  to  control  the  flow  of  information  among 
objects.  More  specifically,  information  can  legally  flow  from  an  object  o;  to  an  object  o * 
if  and  only  if  L{Oj)  <  L{  o*).  All  other  information  flows  are  considered  illegal. 

In  the  Bell-LaPadula  model  this  objective  is  achieved  by  prohibiting  read-ups  and 
write-downs.  That  is,  a  subject  is  allowed  to  read  an  object  only  if  the  security  level  of 
the  subject  dominates  the  security  level  of  the  object.  Similarly,  a  subject  is  allowed  to 
update  an  object  only  if  the  security  level  of  the  former  is  dominated  by  that  of  the  latter. 
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In  our  model,  due  to  the  property  of  encapsulation,  information  transfer  among 
objects  can  take  place  either  (1)  when  a  message  is  passed  from  one  object  to  another  or 
(2)  when  a  new  object  is  created.  In  the  first  case,  information  can  flow  in  both  direc¬ 
tions:  from  the  sender  to  the  receiver  and  back.  The  forward  flow  is  carried  through  the 
list  of  parameters  contained  in  the  message,  and  the  backward  flow  through  the  return 
value.  In  the  second  case,  information  flows  only  in  the  forward  direction:  from  the 
creating  object  to  the  created  one,  e.g.,  by  means  of  supplying  attribute  values  for  the 
new  object. 

A  transfer  of  information  does  not  have  to  occur  every  time  a  message  is  passed.  An 
object  acquires  information  by  changing  the  values  of  some  of  its  attributes.  Thus,  if  no 
such  changes  occur  as  a  result  of  a  method  invocation  in  response  to  a  message,  then  no 
information  transfer  has  been  enacted.*  We  say  that  the  forward  flow  has  been 
ineffective.  This  situation  is  analogous  to  taking  pictures  with  an  unloaded  camera.  The 
information  in  the  form  of  light  is  flowing  into  the  camera  but  not  being  retained  there. 

Similarly,  if  the  return  value  of  a  message  is  nil,  the  backward  flow  has  been 
ineffective.  To  eliminate  the  covert  channel  associated  with  the  receiver  object’s  security 
level  being  dynamically  changed  (in  which  case  the  sender  can  get  back  a  sequence  of 
nil  and  non -nil  return  values  if  it  repeatedly  sends  messages  to  the  same  object),  we  have 
to  require  that  all  security  level  assignments  be  static.  That  is,  the  level  associated  with 

an  object  at  creation  time  cannot  be  changed.  If,  however,  the  security  level  of  the  real- 

*  This  is  true  because  an  object  has  no  means  of  registering  the  very  event  of  a  message  arrival. 
Therefore,  a  covert  channel  is  not  possible  of  the  type  wherein  a  message  causing  a  state  change 
encodes  a  1  and  a  message  causing  none  is  a  0. 
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world  entity  that  the  object  models  must  be  changed,  then  a  new  object  has  to  be  created. 
The  new  object  will  be  exactly  like  the  one  that  it  replaced,  except  for  the  new  security 
level  to  reflect  the  desired  change. 

A  transitive  flow  from  an  object  o\  to  an  object  02  occurs  when  there  is  a  flow  from 
o  i  to  a  third  object  o3  and  from  o 3  to  02- 

All  types  of  flows  discussed  until  now  can  be  termed  direct  flows.  Now,  consider 
what  happens  when  an  object  o\  sends  a  message  gj  to  another  object  o 2,  and  o 2  does 
not  change  its  internal  state  (the  values  of  its  attributes)  as  a  result  of  receiving  g,  but 
instead  sends  a  message  g 2  to  a  third  object  <93.  Further,  suppose  that  p{g2)  contains 
some  of  the  parameters  of  p(g\).  If,  then,  the  invocation  of fa  A  h(  g 2))  with  parameters 
p  ( gi)  results  in  updating  o3  ’ s  state,  a  transfer  of  information  has  taken  place  from  o  1  to 
03.  There  is  no  message  exchange  between  0\  and  o 3,  nor  was  o3  created  by  o  j ,  there¬ 
fore  this  flow  cannot  be  considered  direct.  Moreover,  there  is  no  flow  from  o\  to  o3, 
therefore  this  is  not  a  transitive  flow  either.  This  is  an  instance  of  what  we  call  an 
indirect  flow  of  information.  Note  that  an  indirect  flow  can  involve  more  than  three 
objects.  For  example,  instead  of  updating  its  state,  o  3  could  send  a  message  to  a  fourth 
object  that  would  result  in  updating  the  latter’s  state. 

Both  direct  and  indirect  illegal  flows  of  information  should  be  prevented  (this  would 
also  take  care  of  all  the  transitive  flows)  if  the  system  is  to  be  secure. 

We  assume  that  access  to  internal  attributes,  object  creation  (creation  by  an  object 
of  an  instance  of  itself),  and  invocation  of  internal  methods  are  all  implemented  by  hav¬ 
ing  an  object  send  a  message  to  itself. +  We  now  define  four  built-in  messages  for  that 

There  arc  existing  object-oriented  database  systems  that,  in  fact,  use  this  kind  of 
implementation,  c.g.,  GcmStonc. 
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purpose.  First,  however,  it  is  necessary  to  modify  the  definition  of  message  in  Section  2. 


Definition  2a.  A  message  is  a  triple  g  =  ( h,  p,  r)  where  h  is  the  message  name, 
p  =  (pi,  ...,  pi),  l>  0,  is  an  ordered  set  (list)  of  message  parameters  where 

Pj  e  V  u  A  u  M  u  S,  and  r  is  the  return  value .  □ 

The  difference  is  that  now  a  parameter  can  be  a  method,  an  attribute  name,  or  a 
security  level  as  well  as  a  value. 

A  read  message  is  a  message  sent  by  an  object  o  to  itself  defined  as 

g  =  ( READ,  ( af),  r)  where  aj  e  a(  o).  A  read  message  results  in  binding  r  to  the  value 

of  attribute  ay. 

A  write  message  is  a  message  sent  by  an  object  o  to  itself  defined  as 

g  =  (  WRITE,  (  aj,  vj),  nil)  where  aj  e  a  (  o).  The  effect  of  sending  a  write  message  is  an 
update  of  attribute  aj  with  value  Vy. 

An  invoke  message  is  a  message  sent  by  an  object  o  to  itself  defined  as 
g  =  ( INVOKE,  ( m),  r)  where  me  ji(  o).  Method  m  is  invoked  as  a  result  of  this  mes¬ 
sage. 

Finally,  a  create  message  is  defined  as  g  =  (  CREATE,  {  Vj,  ...,  v*,  5y},  r)  where  p 
is  a  list  of  attribute  values  appended  with  a  security  level.  When  sent  by  an  object  o  to 
itself,  a  create  message  results  in  a  new  object  being  created.  This  new  object  is  assigned 
an  identifier  i  by  the  system.  The  object  inherits  attributes  and  methods  from  o.  The  attri¬ 
butes  are  initialized  with  the  values  vj,  ...,  v*.  The  new  object  is  assigned  security  level 
Sj,  specified  by  o.  The  identifier  /  is  returned  to  o  as  r. 


12 


3.3.  Message  Filtering  Algorithm. 


The  message  filter  is  a  security  element  of  the  system  whose  goal  is  to  recognize 
and  prevent  illegal  information  flows.  The  message  filter  intercepts  every  message  sent 
by  any  object  in  the  system  and,  based  on  the  security  levels  of  the  sender  and  receiver, 
as  well  as  some  auxiliary  information,  decides  how  to  handle  the  message. 

In  this  subsection,  we  outline  an  algorithm  used  by  the  message  filter  and  show  that 
it  indeed  prevents  all  illegal  information  flows. 

Let  g  =  (  h,  p,  r)  be  a  message.  Let  oi  =  ( /j ,  a} ,  Vj ,  |ii)  and 
o 2  =  ( i'2-  fl2’  v2>  M-2 )  be  the  sender  and  the  receiver  objects  respectively.  Let  t\  be  a 
method  invocation  in  o  \  that  was  responsible  for  sending  g.  Finally,  let  1 2  be  the  invoca¬ 
tion  of  the  method  fQl{  h)  in  o2  after  receiving  g.  We  assume  that  every  method  invoca¬ 
tion  t  has  a  status  s(  t).  The  status  is  either  U  (unrestricted)  or  R  (restricted).  The  default 
is  U. 

The  message  filtering  algorithm  is  given  in  Figure  1 .  We  now  argue  informally  that 
this  algorithm  works  correctly,  i.e.,  guarantees  to  prevent  any  illegal  flow  of  information 
among  objects. 

The  first  part  of  the  algorithm  (Case  A)  deals  with  message  sending  between  two 
distinct  objects,  while  the  second  part  (Case  B)  takes  care  of  the  situation  when  an  object 
sends  a  message  to  itself.  There  are  four  subcases  of  Case  A,  by  the  number  of  possible 
ways  in  which  two  security  levels  —  those  of  objects  o  j  and  o2  —  can  be  related.  Also, 
there  are  four  subcases  (with  yet  finer  subdivisions)  of  Case  B,  by  the  number  of  built-in 
messages. 
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Subcases  (2) — (4)  prevent  direct  illegal  information  flows  between  two  distinct 
existing  objects.  When  the  two  security  levels  are  unrelated,  this  is  done  by  blocking  the 
message  completely  (subcase  2).  When  the  sender’s  level  is  strictly  lower  than  the 
receiver’s  level,  the  return  value  is  set  to  nil  by  the  message  filter  to  prevent  any  leakage 
of  information  from  the  receiver  to  the  sender  (subcase  3).  Finally,  when  the  sender  is  at 
a  higher  security  level,  the  invocation  of  the  method  (in  the  receiver)  in  response  to  the 
message  is  given  the  restricted  status  by  the  message  filter  (subcase  4).  This  would 
prevent  the  receiver  from  making  updates  to  its  local  attributes  (see  subcase  l.b  of  Case 
B)  thereby  retaining  sensitive  information  that  could  have  been  extracted  from  the  mes¬ 
sage. 

Direct  illegal  flow  during  the  creation  of  a  new  object  is  prevented  by  letting  the 
create  message  pass  only  if  the  security  level  specified  for  the  new  object  dominates  that 
of  the  creator  object  (subcase  B.3). 

It  remains  to  show  now  that  indirect  illegal  flows  are  also  prevented  by  our  algo¬ 
rithm.  To  understand  how  this  is  done,  it  is  helpful  to  think  of  trees  of  method  invoca¬ 
tions.  Such  a  tree  is  is  shown  in  Figure  2.  Let  tc  be  the  root.  t0  is  a  "spontaneous"  method 
invocation  within  a  user  object.  Let  r,  be  an  internal  node  in  this  tree.  Then  r,  ’s  children 
are  the  method  invocations  that  were  initiated  either  within  the  same  object  directly  by  /,■ 
or  in  another  object  as  a  result  of  receiving  a  message  sent  by  r(  .  Thus,  the  entire  tree  can 
be  viewed  as  the  execution  of  a  user  request. 

Information  can  be  carried  down  a  method  invocation  tree  along  the  parent — child 
links.  Let  and  ti  be  two  internal  nodes.  Suppose  that  t\  is  an  invocation  of  a  method 
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CASE  A:  c>\*o2 


(1)  if  L(0])  =  L(o2) 

let  g  pass;  s(t2)  s(t\) 

(2)  ifL(0l)<>L(o2) 

block  g 

(3)  if  L(0l)<L(o2) 

let  g  pass;  r  nil,  s  ( t2)  <-  s  ( 1 1 ) 

(4)  if  L{o2)<L{ox) 

let  g  pass;  s(  t2)  R 

CASE  B:  oi  =  o2 

(1)  if  h  =  WRITE 

(l.a)  if  s(tO  =  U 

let  g  pass 

(l.b)  if  s(tx)  =  R 

block  g 

(2)  if  /j  =  READ 

let  g  pass 

(3)  if  g  =  (CREATE,  {  v  j,...,  vt,Sy),r) 

(3.a)  if  s  ( t  \ )  =  U  and  (Sj  <  L  ( o  !  )  or  Sj  <  >  L  ( o  \ ) 

block  g; 

(3.b)  if  s(tl)  =  R 

block  g 

(3.c)  if  s(  fj)  =  (/and  L(  0\)  <S} 

let  g  pass 

(4)  if  h=  INVOKE 

let  g  pass;  s(  t2)<r-  s(t\) 


Figure  1.  The  Message  Filtering  Algorithm. 
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in  object  0\,t 2  in  object  o 2  such  that  L(  02)  <  L(  o  1),  and  I2  is  a  child  of  t\.  Then,  by 
making  ti  restricted  (as  in  A.4)  we  cut  off  forward  direct  flow  from  o  \  to  02-  If  we  also 
want  to  prevent  indirect  illegal  flows  from  0\  to  objects  other  than  02,  as  a  result  of  the 
same  message  from  0\  to  <?2-  we  have  to  make  sure  that  all  ancestors  of  1 2  are  made  res¬ 
tricted  as  well.  This  is  taken  care  of  in  subcases  A.l,  A. 3,  A.4,  and  B.4. 

The  general  idea  of  a  message  filter  is  similar  to  that  of  a  law  filter  introduced  by 
Minsky  and  Rozenshtein  [11],  although  their  work  has  no  direct  relation  to  security. 

In  the  standard  kernelized  architecture,  the  message  filter  does  not  have  to  be  made 
trusted,  because  the  actual  mandatory  access  control  is  delegated  to  the  trusted  kernel 
that  includes  a  reference  monitor.  The  kernel  is  part  of  the  operating  system,  wich  is 
based  on  the  traditional  read/write  primitives  to  implement  data  access.  However,  newly 
emerging  operating  systems  based  on  message-sending  primitives  may  radically  change 
the  place  of  the  message  filter  in  the  security  structure  of  the  overall  system.  It  seems 
that,  under  such  conditions,  it  would  be  quite  natural  to  make  the  filter  part  of  the  kernel, 
thus  substituting  it  for  the  reference  monitor  in  this  new  architecture.  This  would  obvi¬ 
ously  necessitate  making  the  message  filter  trusted.  In  our  future  work,  we  plan  to  study 
this  alternative  together  with  its  implications. 
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4.  CJass  Hierarchy  and  Security. 


The  notion  of  classes  is  usually  considered  very  important  for  object-oriented  data¬ 
bases,  if  not  for  object-oriented  systems  in  general.  Most  existing  object-oriented  data¬ 
bases  support  classes. 

The  notion  of  classes  is  akin  to  that  of  relations  in  relational  databases.  Objects  of 
similar  structure  (types  and  names  of  attributes)  and  similar  behavior  (methods)  are 
grouped  into  classes,  just  like,  tuples  of  the  same  structure,  in  relational  databases,  are 
grouped  into  relations.  The  parallel  to  relational  systems  does  not  go  very  far,  however. 
First,  in  relational  databases,  there  is  no  notion  analogous  to  that  of  object  behavior. 
Second,  classes  in  object-oriented  databases  are  represented  by  objects  that  contain 
information  (in  the  form  of  attributes)  on  the  names  and  types  of  attributes  of  the  consti¬ 
tuent  instance  objects  of  the  class  as  well  as  the  methods  common  to  them.  Objects  of 
this  kind  are  called  class-defining  objects,  or  simply  class  objects.  Thus,  there  is  essen¬ 
tially  no  distinction  in  representation  of  data  and  metadata  in  object-oriented  systems. 

We  assume  that  the  reader  has  a  basic  familiarity  with  the  notions  of  inheritance 
and  class  hierarchy.  A  typical  class  hierarchy  has  a  class  OBJECT  at  its  root.  It  also 
includes  a  special  class  CLASS  such  that  every  object  defining  a  class  is  an  instance  of 
CLASS. 

In  Section  3.2  we  discussed  ways  by  which  objects  can  —ansfcr  information  to  one 
another.  Message  sending  and  object  creation  were  mentioned  n  thi  connection.  We, 
then,  went  on  to  define  several  types  of  information  flow.  With  Oe  introduction  of 
classes  and  inheritance,  two  more  (implicit)  ways  of  information  transfer  are  added. 
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Since  a  class  object  (a  class-defining  object)  contains  structure  and  behavior  infor¬ 
mation  for  all  its  instance  objects,  the  latter  have  an  implicit  read  access  to  the  former. 
Thus,  an  information  flow  exists  from  a  class  object  to  an  instance  object.  We  refer  to  this 
type  of  flow  as  a  class — instance  flow. 

Since  classes  inherit  attributes  and  methods  from  their  ancestors  in  the  class  hierar¬ 
chy,  a  class  object  has  an  implicit  read  access  to  all  its  ancestors.  Therefore,  there  is  an 
information  flow  down  along  all  hierarchy  links.  This  type  of  flow  is  designated  inheri¬ 
tance  flow. 

It  is  easy  to  see  that  an  inheritance  flow  is  illegal  unless  the  level  of  a  class  object 
dominates  the  level  of  each  of  its  ancestors.  Similarly,  a  class — instance  flow  is  illegal 
unless  the  level  of  an  instance  object  dominates  that  of  its  class. 

Our  approach  to  dealing  with  illegal  inheritance  and  class — instance  flows  is  to 
implement  the  classification  and  inheritance  features  by  means  of  message  passing.  For 
the  details  of  such  an  implementation  see  [11].  The  purpose  achieved  by  this  approach  is 
to  make  the  implicit  flows  discussed  above  explicit,  i.e.,  realized  by  means  of  messages. 
As  a  consequence,  class — instance  and  inheritance  flows  can  be  checked  by  the  message 
filter,  just  like  forward,  backward,  and  indirect  flows  are. 

It  is  still  a  good  idea,  though,  to  place  the  following  constraints  on  the  way  the  secu¬ 
rity  levels  of  instance  objects  and  subclasses  objects  relate  to  those  of  the  corresponding 
class  objects. 

Security-Level  Constraint  1. 
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If  oj  is  an  object  of  class  cj  ( Cj  also  denotes  the  corresponding  class  object), 

then  L(cj)  <L(oj). 

Security-Level  Constraint  2. 

If  C[  and  Cj  are  classes  such  that  c}  is  a  child  of  c,  in  the  class  hierarchy,  then 

L(ci)  <L(  Cj). 

It  is  important  to  understand  that  the  above  constraints  are  not  introduced  for  secu¬ 
rity  reasons  —  security  is  still  handled  by  the  message  filtering  algorithm  because  all 
flows,  including  the  class — instance  and  inheritance  flows,  are  explicitly  cast  in  the  form 
of  messages  —  and  therefore,  a  violation  of  these  constraints  will  not  lead  to  a  violation 
of  security.  Instead,  a  violation  of  Constraint  2,  for  example,  will  result  in  the  break¬ 
down  of  inheritance  mechanism  by  creating  a  situation  wherein  a  class  object  is 
prevented  by  the  message  filter  from  gaining  access  to  a  method  it  inherits  from  its  parent 
class,  because  the  security  level  of  the  child  does  not  dominate  that  of  the  parent,  as 
required  by  the  constraint. 

Note  that  Constraint  1  is  automatically  satisfied  by  the  message-filtering  algorithm 
(see  subcase  B.3)  at  the  instance-creation  time.  It  is  interesting  to  note,  though,  that  this 
feature  was  originally  included  in  the  algorithm  to  prevent  the  illegal  direct  flow  to  the 
newly  created  object  at  the  creation  time  rather  than  the  illegal  class — instance  flow, 
which  can  take  place  at  any  time  after  the  instance  is  created.  However,  the  provision 
works  equally  well  in  both  cases. 

Constraint  2  is  not  automatically  satisfied  by  the  message  filtering  algorithm,  but  the 
latter  could  be  modified  for  that  purpose.  Alternatively,  the  constraint  could  be  enforced 
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by  supplying  the  object  CLASS  with  a  method  for  creation  of  new  classes  that  would 
include  provisions  for  checking  that  the  security  level  of  the  new  class  is  in  the 
prescribed  relationship  to  the  levels  of  its  parents. 
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5.  Modeling  Multilevel  Entities  with  Single-Level  Objects. 


In  an  object-oriented  data  model,  objects  are  used  to  model  real-world  entities. 
Therefore,  it  may  seem  somewhat  discouraging  that  our  security  model  insists  that  all 
objects  have  to  be  “flat,”  i.e.,  at  a  single  security  level.  Much  modeling  flexibility  would 
be  lost  if  multilevel  entities  could  not  be  represented  in  our  database. 

In  this  section  we  will  demonstrate  that  restricting  objects  to  be  single-level  does 
not  have  to  imply  that  the  same  type  of  restriction  exists  for  entities  that  we  are  trying  to 
model.  We  will  do  so  by  means  of  a  simple  example. 

Suppose  that  there  are  two  security  levels:  U  (unclassified)  and  S  (secret),  the  latter 
dominating  the  former.  Consider  an  entity  e  characterized  by  attributes  A,  B ,  and  C  such 
that  A  and  B  are  at  level  U  and  C  is  at  level  S.  ( e  could  be  a  collection  of  information  per¬ 
taining  to  an  employee  where  A  is  the  employee's  name,  B  is  the  home  address,  and  C  is 
the  salary.)  The  intention  is  to  allow  access  to  C  only  for  users  with  secret  clearance.  All 
other  users  can  access  only  A  and  B.  Entity  e  can  be  represented  by  objects  o  i  and  o2 
such  that  a(  <?  j )  =  ( A,  B),a(o2)  =  (A,  B,  C),L(  o\ )  =  U,  and  L  (  o2 )  =  S.  Object  o2  is 
the  internal  representation  of  entity  e  for  users  with  the  secret  clearance,  while  o  j  is  the 
representation  of  e  for  all  other  users.  The  example  is  illustrated  in  Figure  3.  Attributes  of 
entity  e  have  individual  security  labels  (shown  in  parentheses).  This  is  in  contrast  to 
objects  o  i  and  o2,  which  only  have  labels  at  the  object  level. 

Suppose  now  that  we  have  an  entire  collection  of  entities  of  the  simc  type  as  e  (e.g., 
a  set  of  employee  entities),  i.e.,  entities  with  unclassified  attributes  A  and  B  and  a  secret 
attribute  C.  Let  us  call  this  type  of  entity  X.  In  our  model  each  entity  of  this  type  will  be 


o1  (U)  o2  (S) 


Figure  3.  Representing  a  multilevel  entity  by 
multiple  single-level  objects 


represented  by  two  objects:  one  for  the  users  with  the  secret  clearance  and  one  for  all 
others.  Thus,  we  end  up  with  two  classes  of  objects  for  one  type  of  entity.  The  distinc¬ 
tion  between  the  two  classes  is  based  on  security,  not  semantics,  as  would  normally  be 
the  case  in  object-oriented  databases.  Let  XU  be  the  class  of  the  unclassified  objects  and 
XS  the  class  of  the  secret  objects  representing  entities  of  type  X. 

It  is  convenient,  for  modeling  purposes,  to  relate  classes  XU  and  XS  in  the  class 
hierarchy.  Namely,  if  XS  is  made  a  child  of  XU,  then  it  can  inherit  from  XU  attributes  A 
and  B  and  add  to  them  a  locally  defined  attribute  C.  Figure  4  shows  the  relevant  segment 
of  the  hierarchy.  Note  that  the  class  object  XU  is  placed  at  security  level  U,  and  XS  at 
level  S.  The  effect  of  this  is  that  not  only  do  the  uncleared  users  have  no  access  to  the 
values  of  attribute  C  in  entities  of  type  X,  but  also  they  are  not  even  aware  of  the 
existence  of  this  secret  attribute  because  access  to  the  class  object  XS  is  prohibited  to 
them.  It  is  possible  to  place  the  class  object  XS  at  level  U,  while  keeping  instances  of  XS 
at  level  S.  In  that  case,  the  uncleared  users  will  be  aware  of  the  existence  of  attribute  C 
but  not  of  any  values  of  it  in  instance  objects.  Note  that  such  a  dichotomy  between  the 
class-object  level  and  the  level  of  its  instances  is  in  conformity  with  Security-Level  Con¬ 
straint  1.  The  choice  of  label  forXS  depends  on  the  policy  decision. 

To  carry  our  example  a  little  further,  suppose  that  there  is  a  second  type  of  entity 
that  we  have  to  model,  type  Y.  Y  consists  of  the  same  attributes  at  the  same  security  levels 
as  X  plus  a  new  attribute  D  at  level  U.  The  conceptual  class  hierarchy  (or  schema)  is 
shown  in  Figure  5.  In  that  schema,  Fisa  child  of  X. 
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Let  us  now  address  the  question  of  how  this  schema  can  be  implemented  in  our 
model.  Using  the  idea  of  Figure  4,  we  arrive  at  the  implementation  schema  for  our  data¬ 
base,  shown  in  Figure  6.  The  implementation  schema  takes  into  account  security  level 
assignments  to  attributes  in  the  conceptual  schema  and  transforms  the  latter  into  the  form 
ready  for  actual  implementation  in  a  system  that  uses  our  security  paradigm.  In  particu¬ 
lar,  we  have  four  classes  in  our  implementation  schema:  XU,  XS,  YU,  and  YS.  XU 
represents  the  view  of  X  for  uncleared  users;  XS,  the  view  of  X  for  users  with  the  secret 
clearance;  YU,  the  view  of  Y  for  uncleared  users;  and  FS,  the  view  of  Y  for  users  with  the 
secret  clearance. 

In  Figure  6,  links  between  classes  represent  inheritance  relationships  among  classes. 
It  is  helpful  to  distinguish  between  two  kinds  of  inheritance  in  the  implementation 
schema:  semantic  inheritance  and  security  inheritance.  The  actual  inheritance  mechan¬ 
ism  is  identical  in  both  cases,  but  the  motivation  is  different.  Semantic  inheritance 
corresponds  to  the  usual  notion  of  inheritance  in  object-oriented  databases.  It  is  intended 
to  represent  the  semantic  relationships  among  data  types  found  in  the  conceptual  schema. 
The  notion  of  security  inheritance,  on  the  other  hand,  is  introduced  solely  for  the  purpose 
of  representing  multilevel  entities  in  our  security  paradigm.  Thus,  for  instance,  YU  is  a 
subclass  of  XU  in  the  semantic  sense  because  this  relationship  reflects  the  specialization 
of  the  entity  type  X  into  Y  by  adding  to  the  former  a  new  attribute  D.  On  the  other  hand, 
XS  is  a  subclass  of  XU  in  the  security  sense  because  XS  reveals  a  new  attribute  of  entities 
of  type  X  that  is  not  visible  to  uncleared  users.  Note  that  the  notion  of  security  inheri¬ 
tance  is  in  agreement  with  Security-Level  Constraint  2,  which  requires  that  the  security 
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level  of  a  class  dominate  that  of  its  ancestors. 

Instance  objects,  as  was  discussed  earlier  in  this  section,  do  not  have  to  be  at  the 
same  security  level  with  their  class  object.  By  the  same  token,  instance  objects  may 
sometimes  be  placed  at  different  levels  with  one  another,  just  like  it  may  be  required  that 
real-world  entities  of  the  same  type  have  different  security  classifications.  Our  model 
does  not  prohibit  this,  although  it  would  not  make  sense  of  course  (but  not  violate  secu¬ 
rity)  to  have  some  instance  objects  at  levels  higher  than  the  corresponding  class  object. 


29 


6.  Review  of  Relevant  Research 


Object-oriented  approach  has  been  a  major  area  of  research  in  the  context  of  pro¬ 
gramming  languages,  knowledge  representation,  and  databases  for  some  years  now  (e.g., 
see  [7, 13, 17]).  In  spite  of  this,  there  has  been  relatively  little  work  on  security  related 
issues  in  the  object-oriented  databases,  although  some  work  does  exist.  Initial  efforts  in 
[2, 3, 12]  handle  only  the  discretionary  access  controls.  Meadows  and  Landwehr  [10]  are 
the  first  to  model  mandatory  access  controls  using  object-oriented  approach,  however, 
their  effort  is  limited  to  considering  the  Military  Message  System.  Spooner  in  [14]  takes 
a  preliminary  look  at  the  mandatory  access  control  and  raises  several  important  concerns. 
In  [4,5,8, 15, 16],  objects  can  be  multilevel.  This  means,  for  example,  that  an  object’s 
attributes  can  belong  to  different  security  levels,  which  in  turn  means  that  that  the  secu¬ 
rity  system  must  monitor  all  methods  within  an  object.  As  we  have  argued  in  the  intro¬ 
duction,  we  consider  it  to  be  contrary  to  the  spirit  of  the  object-oriented  paradigm. 

Finally,  Lunt  and  Millen  in  [9]  mention  some  problems  associated  with  having  mul¬ 
tilevel  objects.  In  their  model,  only  single-level  objects  are  permitted;  however,  the 
notion  of  subjects  is  still  retained,  and  subjects  are  assigned  security  levels. 
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7.  Conclusions  and  Future  Work. 


An  examination  of  the  object-oriented  data  model  leads  one  to  believe  that  there  is 
much  in  it,  particularly  in  the  notion  of  encapsulation,  that  makes  this  model  naturally 
compatible  with  the  notion  of  security.  However,  until  r~>w,  relatively  little  use  has  been 
made  of  this  apparent  compatibility. 

This  paper  is  part  of  an  effort  to  develop  a  better  understanding  of  the  interactions 
between  multilevel  security  and  the  object-oriented  data  model.  This  interaction,  in  our 
opinion,  can  be  very  subtle,  and  for  that  reason,  we  chose  a  formal  approach.  We  wanted 
to  state  precisely  all  critical  assumptions,  which  are  necessary  if  we  hope  to  use  this 
paper  as  a  departure  point  for  further  research. 

We  believe  that  there  is  much  more  interesting  work  to  be  done  in  the  area  of 
object-oriented  multilevel  security.  In  particular,  we  would  like  to  be  able  to  construct  a 
complete  and  unified  formal  model  of  data  and  security  based  on  the  object — message 
paradigm.  Initial  steps  have  been  taken  in  this  direction  in  the  present  paper,  but  more 
remains  to  be  done.  For  example,  we  would  like  to  formalize  the  notion  of  classes  and 
inheritance  in  a  way  adaptable  to  security  concerns. 

In  Section  5,  we  presented  some  ideas  for  representing  multilevel  entities  using 
multiple  objects  at  different  security  levels.  These  ideas  were  illustrated  by  an  example. 
The  subject  clearly  merits  further  study,  and  perhaps  one  should  address  the  issue  of 
designing  an  algorithm  for  multi-object  representation  of  multilevel  entities. 

The  issue  of  polyinstantiation  in  the  context  of  object-oriented  databases  has  not 
been  discussed  here.  We  plan  to  study  this  in  the  future  to  see  how  this  relates  to 
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polyinstantiation  in  relational  databases. 

Implementing  the  class  and  inheritance  mechanisms  by  message  passing  is  essential 
to  our  approach  to  enforcing  security.  In  a  system  that  follows  such  an  implementation, 
all  information  flows  are  rendered  explicit,  and  therefore  controllable  uniformly  by  the 
message  filter.  Consequently,  our  future  work  should  address  this  issue  of  implementa¬ 
tion,  as  it  relates  to  modeling  security,  at  a  more  detailed  level. 

Finally,  an  additional  research  direction  of  significant  interest  is  the  study  of  the 
potential  benefits  of  message-based  operating  systems  to  implementation  of  the  proposed 


security  model. 
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MISSION 


Rome  Air  Development  Center 


RADC  plans  and  executes  research,  development,  test  and 
selected  acquisition  programs  in  support  of  Command,  Control, 
Communications  and  Intelligence  (C*I)  activities.  Technical  and 
engineering  support  within  areas  of  competence  is  provided  to 
ESD  Program  Offices  (POs)  and  other  ESD  elements  to 
perform  effective  acquisition  of  CSI  systems.  The  areas  of 
technical  competence  include  communications,  command  and 
control,  battle  management  information  processing,  surveillance 
sensors,  intelligence  data  collection  and  handling,  solid  state 
sciences,  electromagnetics,  and  propagation,  and  electronic 
reliability /maintainability  and  compatibility. 


